1. Field of the Invention
The present invention relates, in general, to the Wireless Universal Serial Bus (WUSB) protocol and to devices that implement the WUSB protocol (i.e., WUSB devices), and, more particularly, to methods of managing buffers in WUSB devices with isochronous IN endpoints to limit the amount of memory required for endpoint buffers and to reduce the complexity of managing the endpoint buffers while complying with WUSB specifications for data packets.
2. Relevant Background
Universal Serial Bus (USB) communications have significantly improved communications between personal computers (PCs) or other host devices and external peripheral devices such as storage devices, scanners, personal digital assistants (PDAs), external hard drives, keyboards, mice, video cameras, printers, cell and other telephones, displays, voice recorders and microphones, and other devices that communicate digital information with applications and/or embedded systems on the PC or host device. In 2005, analysts estimated there were over 500 million USB products in use. USB provided an asynchronous serial interconnect between a host and one or many peripheral devices. Initially, USB was a protocol useful for wired connections, e.g., the peripheral needed to be plugged into a port on the host PC, but the Wireless Universal Serial Bus (WUSB) specification defines a protocol for a host to communicate at high bandwidths wirelessly with peripheral devices, such as via Ultra-WideBand (UWB) radio technology, without the need for cables or physical ports. The WUSB is a logical bus that supports data exchange between a host device and a wide range of simultaneously accessible peripherals or devices.
The WUSB Specification, Rev. 1.0, issued on May 12, 2005 is generally based upon and expands the USB protocol. In USB communications, each USB device or peripheral is connected to a hub or directly to a host (e.g., a PC with a USB host controller). Under WUSB, there are no hubs and the peripherals or WUSB devices communicate directly with the host and, in some cases, a device wire adapter (DWA) is connected or wired to one or more USB devices to allow the wired USB devices to communicate in a wireless fashion with the host (e.g., a DWA can be thought of as acting as a host for a wired USB system). In either case, the host controls all communications on a USB or WUSB bus and only one device communicates with the host at a time. When a device is first connected to a host, the host detects its presence and requests basic information from the device such as communication speeds supported by the device, the bandwidth the device requires, and what data transfer type the device utilizes. The initialization process is referred to as enumeration and includes the host assigning a unique address to the device. There are four data transfer types used to transmit USB and WUSB data: control, bulk, interrupt, and isochronous. Isochronous transfer allows devices to transfer large amounts of data in real time by guaranteeing a delivery time or bandwidth for the device data to be transmitted but without error correction. Devices that utilize isochronous transfer such as video or web cameras, music playing devices such as USB speakers, microphones, and the like, have to be tolerant of occasional corrupt data packets arriving at the destination.
Endpoints are provided within each device or peripheral in a USB or WUSB system. Endpoints are a uniquely addressable portion of a device that is considered the terminus of communication flow between a host and the device and are utilized for transmitting and receiving data over the bus. Typically, there are sixteen addressable endpoints available in each device and each contains an address number and a direction or endpoint number. The endpoint address references one of the 16 endpoint buffers or registers within the device and the endpoint number defines if the data is traveling to or from the host, with the reference being from the host's point of view. Hence, an “IN endpoint” is an endpoint that is transmitting data from the device to the host and an “OUT endpoint” describes data that is traveling from the host to the device. The communication exchange between a host and a device that is initialized or set up during enumeration is referred to as a “pipe” which is a virtual connection between a device's endpoints and the device's controlling software or drivers that are located in the host. The pipe is a pathway for all data exchanged between the host and the device. A significant, ongoing challenge for WUSB developers is to design isochronous endpoints or WUSB devices with isochronous endpoints to effectively manage communications on the pipes (or over the WUSB bus) and buffering of data at the endpoints. Preferably, such designs would be created to control the amount of memory required to support buffers or registers for each endpoint while supporting all requirements of the WUSB specification because a WUSB device must implement all of the required features of the WUSB protocol in order to communicate via a WUSB channel or pipe with a host.
Specifically, the issue of buffer management for wireless USB or WUSB isochronous IN endpoints is an issue that has to be addressed when designing or configuring a WUSB device or peripheral. During the data phase of a WUSB transaction, a series of data packets are transmitted and this data transfer is called “data bursting.” FIG. 1 illustrates WUSB data bursting according to the WUSB protocol. In order to guarantee reliable data delivery, WUSB systems or clusters, such as a cluster 100 including a transmitter or device with an IN endpoint 110 and a receiver such as a host device 120, perform data bursting of packets 130 using a simple sliding window protocol to attach a sequence number with each packet 130. As shown, the transmitter 110 includes a data buffer 112 that stores data from an endpoint function prior to its being transferred by the data transmitter 114, and, similarly, the receiver or host device 120 includes a data receiver 126 that receives the packets 130 over the WUSB bus or a pipe in such a bus in a receiving window and passes the data to a data buffer 128 for later transfer to a host application, function, or embedded system for use. According to the WUSB Specification, buffer size selection for an isochronous IN endpoint is an application specific decision, and the only guidance is that the size should be selected by balancing several factors including desired short term error tolerance, cost, and acceptable stream delay and/or latency. In other words, buffer size and buffer management is left mainly to the WUSB developer and little guidance is provided in how best to achieve desired results such as reduced memory, lower cost, and/or limited delay and errors.
Besides providing a sequence number, each WUSB isochronous packet is required to have a special format with some of the specific requirements being listed in Table 1 below. WUSB isochronous IN endpoints must aggregate isochronous data into the largest packets that it can send over the air or WUSB bus without splitting a single data segment across multiple WUSB packets. In isochronous IN transfer, the wPresentationTime field is the sample time of the first segment in the packet. The interval between two consecutive data segments is assumed to be fixed in one packet and is used to determine the presentation time of the following segments in the packet. If one segment has no data, the endpoint should set its length as zero explicitly. In response to a request for data from the host or receiver 120, the isochronous IN endpoint in receiver 110 responds by transmitting the oldest data in its buffer 112 for each WUSB isochronous IN request. When the buffer 112 is full, the isochronous IN endpoint 110 discards the oldest data in the buffer 112. If the isochronous IN endpoint has already tried to transmit the discarded data, it attempts to transfer the oldest available non-discarded packets using the same burst sequence number(s) as the discarded packet(s). Additionally, it may be desirable for the WUSB isochronous IN endpoint in receiver 110 to support dynamic switching and/or to be continually scalable, which may allow the maximum packet size or interval to be changed without interrupting its transfer. These optional features make isochronous transfer smoother over the unstable wireless channel.
TABLE 1WUSB isochronous packet formatOffsetFieldSizeValueDescription0bmAttributes1BitmapEndpoint number, IDATA, Direction1bmStatus1BitmapBit 4:0 is Sequence Number2bNumIsoSegments1NumberThis field indicates the number of datasegments that are contained in the datapayload of the packet. There must be atleast one data segment in an isochronousdata packet.3wPresentationTime2NumberThe presentation time on the WirelessUSB channel associated with Data1.wPresentationTime has a 125 micro-second granularity.5wLength12NumberThe length of the data in data segment1 (Data1) in bytes.7Data1VarRawDataThe data for data segment one.. . .VarwLengthN2NumberThe length of the data in data segmentN (DataN) in bytes.Var + 2DataNVarRawDataThe data for data segment one.
The WUSB Specification, Rev. 1, released by the USB Industry Forum provides the general data bursting model as illustrated in FIG. 1. This does not provide a complete solution as to buffer management for WUSB isochronous IN endpoints, which are responsible for buffering data from an application on a WUSB device or peripheral and packaging the data in WUSB isochronous packets. In the general data bursting model of cluster 100, the transmitter 110 has a data stream that is logically segmented into maximum packet sized portions. It also maintains a sliding transmit window in its data transmitter 114 that controls how sequence numbers are associated with each data packet 130 for the next transaction data phase. The transmitter 110 must associate sequence numbers with data buffer segments in strict, ascending sequence number order. The receiver 120 maintains a receive window in its data receiver 126 that identifies which data sequence numbers (and by association which data packets) it will retain for use from the coming transaction. When the transaction is done, the receiver 120 wipes the sequence numbers of the retained packets from the receive window and advances the window for new packets. As shown in FIG. 1, the receiver 120 sends the current receive window as burst acknowledgment information to the transmitter during the handshake phase of the transaction. When the transaction is an OUT transfer, the burst acknowledgement is in the data payload of a Handshake Packet. When transaction is an IN transaction, the burst acknowledgement is in a subsequent Micro-scheduled Management Command (DINAck in WDTCTA information block as specified by the WUSB Specification). The burst acknowledgement is a bit vector representation of the receive window. The ‘1’ bits in the bit vector represent the receive window. The receiver 120 must use data received in strict ascending sequence number order (except in isochronous discard cases). In the WUSB specification, the following variables are defined to support data bursting: Maximum Packet Size (MPS), which is the nominal data unit size for all data packets; Maximum Burst Size (MBS), which is the largest number of packets an endpoint can accommodate in a single data phase and the MBS in FIG. 1 is 3; and Maximum Sequence (MaxSeq), which is the range of sequence numbers that must be used when transferring data to this endpoint and the actual range of sequence numbers for the endpoint is zero to (MaxSeq-1).
The WUSB Specification also provides a simple example of an isochronous IN endpoint that may be used to buffer and package data from an application in a device wire adapter (DWA), but this example also fails to satisfactorily address memory or buffer management issues associated with WUSB data transfers. FIG. 2 shows a data burst process example for a DWA with an isochronous IN endpoint provided in the WUSB specification. In the example process 200, in response to the first poll attempt by the host which occurs before frame 642, the DWA begins transactions to the downstream USB 2.0 function endpoint (i.e., to one of the downstream wired USB devices or peripherals plugged into the DWA) in the next frame (i.e. 643). In each frame after 642, the DWA conducts isochronous IN transactions to the USB 2.0 function endpoint. The DWA continually stores all of the data received during a service interval into the buffer and records the frame time of the first data received from the USB 2.0 device during the interval. In the next interval (N+1), the host polls the DWA's isochronous function endpoint, and the DWA returns the data it has ready to transmit. At the time the WDTCTA during interval N+1 is transmitted by the host, the DWA has not completely received any data from the USB 2.0 function endpoint during the interval, and so the DWA only transmits the complete data it does have. The format of the resultant data packet is illustrated in FIG. 2. Since two packets were received from the USB 2.0 function endpoint in interval N, in response to the second WDTCTA poll, the DWA transmits a packet that includes the two samples received and the presentation time of when data was first received. In the next interval (N+2), the host polls the DWA's isochronous function endpoint and receives the next set of isochronous segments ready (i.e., Data 3, 4 and 5), with the frame number where the first packet (i.e. Data 3 at 645) was received from the USB 2.0 function endpoint.
Neither the general data burst model shown in FIG. 1 nor the DWA isochronous IN endpoint example shown in FIG. 2 are completely successful in meeting the demands for effective buffer management and control of WUSB device memory requirements. The general data burst model is not particularly well suited to isochronous transfer because of the required special format for the isochronous data packet. Specifically, besides raw data, each isochronous data packet includes some variable fields including presentation time and the number of segments. The general data burst model cannot provide or pre-define these fields for each packet. Further issues include the fact that the WUSB protocol does not require individual isochronous data packets to be maximum packet size but yet a single data segment cannot be split into multiple packets. The DWA IN endpoint example involves data segments being stored in an IN endpoint buffer in WUSB isochronous packet format. The presentation time, the number of segments, and the length variables for each WUSB packet are stored along with the raw data in the IN endpoint buffer. This exemplary method of controlling endpoint communications allocates a significant amount of memory in the WUSB device containing the endpoint to store the additional information (i.e., the data required of WUSB packets beyond the raw data). Further, if the maximum packet size or MPS is changed, the endpoint needs to repackage all data segments in the buffer and rearrange their position in the buffer. This makes buffer management very complex, and as a result, it is difficult to use this model to support dynamic switching and to configure DWAs and other WUSB devices with IN endpoints that are continuously scalable. In addition, the DWA IN endpoint example shown in FIG. 2 does not provide methods to associate the packets with the sequence numbers, to discard data, or to reuse the sequence number when the buffer overflows.
Hence, there remains a need for improved methods, and devices that implement such methods, for managing buffers of isochronous IN endpoints in WUSB devices. Preferably such buffer management methods would provide solutions that use less memory than the simple examples provided in the WUSB Specification, Rev. 1.0 while still fully complying with requirements placed on IN endpoints and isochronous data packets transmitted to hosts in WUSB clusters or systems by WUSB protocols.